The changes look OK to me. Can you squash them down to two commits - code in one, dts and README in the other - then force push it to your branch?

I agreed with pelwell - all looks fine except for wanting to be in only 2 commits.

Do note the detail in https://pip.raspberrypi.com/categories/685-app-notes-guides-whitepapers/documents/RP-003472-WP/Using-a-DSI-display.pdf which describes the DSI clock structure for vc4 and the use of integer dividers.
I haven't computed all the numbers, but gut feel is that you won't get the exact 78000kHz pixel clock you're asking for. On two lanes vc4 the nearest was 83333kHz, and I suspect the same is true on 4 lanes. For consistency I've tended to do the fixup manually and use that in the mode definition so that the same output is generated on both platforms.

My apologies for the PR mess. I don't do this very often.

It wasn't a mess, and it's not a problem. Adding patches to address specific review points can make things easier to follow, but we like to keep things tidy when merging, particularly avoiding intermediate "bad" states that would catch somebody out if bisecting to find when a bug was introduced. GitHub makes it easy to squash at merge time, but that's only useful when a whole PR results in one commit.

Merged offline, in order to fix up the commit messages and whitespace (which was forgotten, then patched up in a 3rd commit...)